Fixes #27962

Summary

Two coordinated platform fixes to make isOwner()-based authorization work correctly on IngestionPipeline and to close a long-standing gap on the trigger endpoint:

1. Owner inheritance — IngestionPipeline.owners now inherits from the parent referenced by service (Service / TestSuite / App). Inherited owners are tagged inherited: true, indexed for search, and visible to the policy evaluator. Test-suite pipelines inherit transitively from the underlying Table via TestSuiteRepository.setInheritedFields.
2. Trigger authorization — POST /v1/services/ingestionPipelines/trigger/{id} previously skipped authorizer.authorize(...) entirely, so any authenticated user could trigger any pipeline. It now authorizes against MetadataOperation.TRIGGER (the existing enum value already declared in the method for limits.enforceLimits — we just wire it to the authorizer).

A coordinated set of seeded-policy updates + idempotent upgrade migration preserves pre-fix behavior for default roles that previously had broad capability, so no customer is surprised by the new authz check on the trigger endpoint.

What's changing

1. IngestionPipelineRepository.setInheritedFields override

@Override
public void setInheritedFields(IngestionPipeline ingestionPipeline, Fields fields) {
  EntityReference serviceRef = ingestionPipeline.getService();
  if (serviceRef == null) return;
  try {
    EntityInterface parent = Entity.getEntity(serviceRef, "owners,domains", ALL);
    inheritOwners(ingestionPipeline, fields, parent);
    inheritDomains(ingestionPipeline, fields, parent);
  } catch (EntityNotFoundException e) {
    LOG.debug("Parent service {} not found for ingestion pipeline {}; skipping inheritance",
        serviceRef.getFullyQualifiedName(), ingestionPipeline.getFullyQualifiedName());
  }
}

• Mirrors the established pattern (TableRepository.setInheritedFields:311-321, TestSuiteRepository.setInheritedFields, etc.).
• Uses the existing inheritOwners / inheritDomains helpers (EntityRepository.java:4510-4525), which already null-guard and tag refs with inherited=true.
• try/catch EntityNotFoundException protects GET / list endpoints from 500s when a service is soft-deleted with orphan pipelines.
• setFieldsInBulk already routes through super.setFieldsInBulk → base setInheritedFields(List) → per-entity call, so list endpoints get inheritance for free. No bulk override needed.

2. IngestionPipelineResource.triggerPipelineInternal authorize call

Adds the missing authorizer.authorize(...) call to the existing OperationContext(entityType, MetadataOperation.TRIGGER) that was already built in the method:

public PipelineServiceClientResponse triggerPipelineInternal(
    UUID id, UriInfo uriInfo, SecurityContext securityContext, String botName) {
  OperationContext operationContext = new OperationContext(entityType, MetadataOperation.TRIGGER);
  authorizer.authorize(securityContext, operationContext, getResourceContextById(id));
  if (pipelineServiceClient == null) { ... }
  // ... rest unchanged, including limits.enforceLimits(...)
}

• Placed before the pipelineServiceClient == null early-return so authz fires even in environments without an Airflow client (tests, dev, customer instances without pipeline service).
• Uses the existing TRIGGER operation value rather than EDIT_ALL, consistent with upstream AI #200 - Add TRIGGER permission to application bots #25113 (AI #200 - Add TRIGGER permission to application bots) which already established Trigger as a discrete, explicitly-granted operation.
• getResourceContextById(id) builds a ResourceContext that loads owners for authz, so the inherited owners populated by Change 1 are visible to isOwner() evaluation.

3. Seeded policies updated for Trigger + upgrade migration

EditAll does not imply Trigger (per CompiledRule.matchOperation:221-224 — only Edit*-prefixed ops are covered by EditAll). To preserve pre-fix behavior for default roles that previously had broad capability, six seeded policies receive Trigger via an idempotent migration:

Migration (migration/utils/v1129/MigrationUtil.addTriggerOperationToDefaultPolicies) iterates the six (policy, rule) targets and calls the existing idempotent v160.MigrationUtil.addOperationsToPolicyRule helper. Wired into:

• migration/{mysql,postgres}/v1129/Migration.java — runs on upgrade to 1.12.9 (companion empty SQL placeholders in bootstrap/sql/migrations/native/1.12.9/{mysql,postgres}/).
• migration/{mysql,postgres}/v1130/Migration.java — runs again on upgrade to 1.13.0 as an idempotent safety net (existing runDataMigration body extended with the call).

Deliberately out of scope:

• AutoClassificationBotPolicy — EditAll is scoped to Table / Container only; Trigger doesn't apply to those resources, so adding it would be a no-op.
• DataConsumerPolicy — no EditAll, no EditOwners; Data Consumers genuinely shouldn't trigger pipelines.
• OrganizationPolicy-NoOwner-Rule — adding Trigger here would re-introduce trivial-trigger for any unowned entity via noOwner().
• OrganizationPolicy-Owner-Rule already grants [All] (which includes Trigger) to isOwner(), so no change needed.
• CompiledRule.matchOperation — no platform-wide semantic change. EditAll → Trigger would have been a hard rule on the operator. We modify shipped policies, not the operator's behavior, so customer-built EditAll policies remain unchanged and customers retain control over which roles trigger.

4. Tests

New file: openmetadata-integration-tests/src/test/java/org/openmetadata/it/tests/IngestionPipelineOwnerInheritanceIT.java. Two tests in the new SDK-client framework (the old IngestionPipelineResourceTest.java was removed in #26204):

1. testInheritedOwners_fromService — service owner appears on pipeline GET with inherited: true.
2. testIsOwnerPolicy_appliesToEditAndTrigger — full Policy → Role → User chain with Operations: [EditAll, Trigger], Condition: isOwner(). Owner can PATCH displayName + POST /trigger; non-owner gets precise permissionNotAllowed(USER2, [EditDisplayName]) / permissionNotAllowed(USER2, [Trigger]) 403s.

Behavior change to call out

/trigger now requires Trigger. Three groups of identities are affected:

Can trigger after the fix:

• Admins (unchanged — via All).
• Owners of the parent Service / TestSuite / App, via the default OrganizationPolicy-Owner-Rule. Inheritance fix makes this fire automatically.
• Users with the default DataSteward role (via the migration above).
• All seeded bots that previously had broad EditAll: Ingestion, Application, Lineage, Profiler, Quality, Usage.
• Anyone granted Trigger explicitly in a custom policy.

Cannot trigger after the fix (intentional tightening):

• Default DataConsumer role.
• AutoClassificationBot (its EditAll scope doesn't cover ingestionPipeline).
• DefaultBot / ScimBot (no broad edit grant).
• Generic authenticated users with no ownership and no Trigger grant — closes the pre-fix trivial-trigger hole.

Customers should audit (the narrow regression surface):

• Custom automation that calls /trigger using a non-admin / non-default-bot identity needs an explicit Trigger grant.
• Custom-built roles with broad EditAll on ingestionPipeline (not the default DataSteward, which is covered by the migration) need Trigger added to keep their pre-fix trigger capability.

Unaffected:

• Scheduled Airflow runs — the scheduler fires DAGs directly; the metadata CLI only does GET /pipelineStatus and PUT /pipelineStatus, neither of which calls /trigger.

Why this shape

• Trigger remains discrete — consistent with upstream AI #200 - Add TRIGGER permission to application bots #25113. EditAll is the "broad edit capability" operator and Trigger is an "action" operation (alongside Deploy, Kill). Conflating them would weaken the operation model and was rejected in favor of explicit seeded-policy grants.
• DataStewardPolicy gets Trigger directly rather than relying on the ownership-edit escalation. The capability is functionally already there for stewards; making it explicit removes the indirection and gives a cleaner audit trail (one Trigger event vs. an EditOwners PATCH followed by a Trigger).
• Seeded policies are modified via data, not via operator semantics so customer-built EditAll policies retain customer-controlled semantics. Customers who want broader trigger access add Trigger to their own roles; customers who want stricter trigger gates (like Orsted) get exactly what their isOwner() policy already expressed.

Test plan

• IngestionPipelineOwnerInheritanceIT#testInheritedOwners_fromService passes.
• IngestionPipelineOwnerInheritanceIT#testIsOwnerPolicy_appliesToEditAndTrigger passes.
• Full mvn -pl openmetadata-integration-tests -am clean install -DskipTests builds cleanly.
• mvn spotless:apply clean.
• Local upgrade smoke test: brought up a fresh 1.12.9 stack, confirmed Trigger present in IngestionBotPolicy / LineageBotPolicy / ProfilerBotPolicy / QualityBotPolicy / UsageBotPolicy / DataStewardPolicy post-migration via GET /api/v1/policies/name/{name}?fields=rules.
• Six API scenarios validated end-to-end against a deployed stack with metadata-ingested data (TestSuite pipeline, Metadata pipeline, Profiler pipeline, default-Owner-Rule, IngestionBot regression check, admin sanity).
• Playwright UI specs cover owner-can / non-owner-denied / inherited-owner across the agents tab.
• Reindex ingestion_pipeline_search_index after deploy so the UI owner filter sees inherited owners.

Summary by Gitar

• Refactored log storage:
  • Made closeStream idempotent by returning early if log storage is not configured instead of throwing an IllegalStateException.

_{This will update automatically on new commits.}